feat(engine): give CreateInviteLink a production mint path - #1321

What

Command::CreateInviteLink fell through the facade catch-all, so mint_invite_grant and the durable invite store had no caller outside #[cfg(test)] — the unwired-plane shape. This wires the arm end to end.

grants/invite_mint.rs composes the three effects one mint needs:

1. re-sign the vault root's committed set with the link's row in it,
2. record the RecordedInvite durably,
3. publish the re-sealed scope root,

and returns the bearer capability only after all three land.

Why this order

A committed entry no RecordedInvite names is authority no revoke_invite_link call can cut (invite_store.rs header states it), while a record whose row never published is inert — convert_invite_claim refuses it as uncommitted. So the record lands before the publish, on the ack-after-durable rule the accept flow already follows, and a failure at either step returns an error and no URL fragment.

The publish is not optional. convert_invite_claim reads the permission out of CommittedScope.commitment.entries and treats absence as revocation, so a mint-and-persist half would produce exactly the unclaimable link #1240 already calls worse than a refused mint.

The read edge

OwnerRotationNet::resolve_vault_root is new. The CascadeResealResolver arm proves its target a descendant by its ascent link, which a vault root never carries — so the two share one body and differ only in the root binding they require. Two hardening changes came out of review:

• the shared body now binds envelope.id to the caller's label, the way WriteWaveNet already does and for the same stated reason (the root gate binds envelope.scope but not the id, and every AAD a re-seal authors binds the id);
• CascadeTarget carries carried_ascent_link, read off the gate-passing section, so a re-seal takes "does this root owe an ascent link" from the record it replaces instead of a hardcode. The mint refuses a root that carries one.

Fail-closed checks on the produce side

extend runs the release-active check_publishable (grant-set ceiling, duplicate tag, ledger ≡ commitment) before anything is signed, and the mint refuses release-active when the committed set names a different scope root than the one it publishes at — the gate pins those equal on a read, and this refuses rather than trusting that it ran (AGENTS.md rule 8).

Surfaces

• CommandOutcome::InviteLinkMinted(MintedInviteLink) — the invite secret, the owner contact bundle a claimant seals to, the scope-root name, and the bearer-write flag. The engine knows no origin, so composing the URL is the host's; Debug is hand-written on both so neither prints the capability.
• WASM getters inviteSecret / ownerContactCode / scopeRootName / isBearerWrite. packages/client does not surface command outcomes at all yet, so no TypeScript changed. The crate module header said "no secret key material crosses at all"; that is no longer true and now states the residual instead.
• EngineError::UnsupportedTarget { check } — a node this build cannot act on is neither malformed input nor an unimplemented command.
• OwnerRotationNet.owner_pointer_seed becomes Option, so an arm that runs no sweep is not handed the seed that derives the scope pointer's signing key. A consult without it refuses rather than skipping.

Scope

The engine holds no node-to-scope mapping, so only the vault root names a scope root a link can be minted on; any other node is refused with invite-target-is-not-a-scope-root. Inviting to a folder below the root mints that folder's scope first, which is the grant-creation arm's work.

Residuals, stated rather than fixed

• An invite is broader than a personal read grant. create_read_grant mints a fresh scope at epoch 1 with no history; an invite adds a row to the scope root's existing set, so the bearer gets its current seed and the retained history links that walk back from it — every epoch the owner has cut, including cuts made to revoke someone. Narrowing it means minting a fresh scope per link, which is grant-creation work. Documented on Command::CreateInviteLink for the host UI.
• Links carry no deadline and no facade revoke exists yet. expires_at is None because the command carries no expiry term; a read-link revocation is a cut published with a read rotation, so it needs the rotation trigger and a way for a host to name a link — a rotation-arm slice.
• A failed publish spends an invite-record slot. The record is deliberately kept: dropping it would risk forgetting a row that landed after all, the one state nothing can revoke. Bounded at MAX_INVITE_RECORDS and then refused visibly as invite-records-full; the fix is a prune path, which belongs with revoke.
• The wasm getter leaves the capability unwiped in linear memory — wasm-bindgen frees the returned buffer without zeroizing. Documented at both the module header and the getter.

Tests

New, in the engine Test gate:

• grants::invite_mint — the recorded link answers to the returned fragment's identity and its tag is the one conversion re-derives and is in the published owner-signed set; an existing grantee's blob survives the mint; a set naming another scope root, a root carrying an ascent link, and a caller who did not sign the set are all refused before anything is signed, recorded or published; a mint whose record does not land publishes nothing; a publish that fails still leaves the record and hands out no capability.
• net::rotation — the descendant edge refuses the vault root and the new edge reads it; a record claiming another node yields no re-seal material.
• tests/facade.rs — createInviteLink leaves the unimplemented table, refuses a node that names no scope root, and reaches availability on an unresolved root.

Closes #1240
Closes #1165

Summary by CodeRabbit

• New Features
  • Added support for creating invite links from eligible vault roots.
  • Invite links are securely recorded and published before being returned.
  • Exposed invite details, scope information, and write access status through the web interface.
• Bug Fixes
  • Added clear handling for unsupported targets and unavailable vault roots.
  • Improved root resolution and validation for descendant and vault-root scopes.
• Security
  • Added authorization, scope validation, and fail-closed behavior for invite creation.